Synchronization process negotiation for computing devices

ABSTRACT

A methodology providing “synchronization process negotiation” is described. Synchronization process negotiation is the methodology of negotiating between two or more devices exactly what synchronization process (protocol) is to be employed to effect synchronization of the devices. The methodology, which is adaptable to existing synchronization protocols, takes into account the actual synchronization capabilities or built-in support (if any) of each device whose data is to be synchronized (e.g., by a synchronization engine). The methodology may be implemented by adapting a given synchronization protocol (which itself may be one of a variety of types) to include a “negotiation phase” at the beginning of the synchronization, during which the devices involved will exchange information about the capabilities of one or more devices. The individual attributes for a client are communicated as synchronization parameters in attribute/value pair form. Once this negotiation phase has been completed, the synchronization can then proceed in a manner that is most efficient for the features available.

RELATED APPLICATIONS

[0001] The present application claims the benefit of priority from andis related to the following commonly-owned U.S. provisional application:application Ser. No. 60/122,592, filed Mar. 3, 1999. The disclosure ofthe foregoing application is hereby incorporated by reference in itsentirety, including any appendices or attachments thereof, for allpurposes. The present application is also related to the followingcommonly-owned U.S. patent applications, the disclosures of which arehereby incorporated by reference in their entirety, including anyappendices or attachments thereof, for all purposes: application Ser.No. 09/020,047, filed Feb. 6, 1998, and entitled Methods for MappingData Fields from One Dataset to Another in a Data ProcessingEnvironment; application Ser. No. 09/136,215, filed Aug. 18, 1998, andentitled System and Methods for Synchronzng Two or More Data Sets;application Ser. No. 09/136,212, filed Aug. 18, 1998, and entitled DataProcessing Environment with Methods Providing ContemporaneousSynchronization of Two or More Clients; and application Ser. No.08/923,612, filed Sep. 4, 1997, and entitled System and Methods forSynchronzng Information Among disparate datasets.

COPYRIGHT NOTICE

[0002] A portion of the disclosure of this patent document containsmaterial which is subject to copyright protection. The copyright ownerhas no objection to the facsimile reproduction by anyone of the patentdocument or the patent disclosure as it appears in the Patent andTrademark Office patent file or records, but otherwise reserves allcopyright rights whatsoever.

BACKGROUND OF THE INVENTION

[0003] The present invention relates generally to synchronization ofdata—that is, the process of taking two different stores of data (“datastores”), comparing them to identify differences, and applying changesto one or both to make them identical. More particularly, the presentinvention relates to a methodology for negotiating the synchronizationprocess that is to occur among two or more computing devices, in adata-processing or computing environment.

[0004] With each passing day, there is ever increasing interest inproviding synchronization solutions for connected computing devices,particularly information appliances. These “appliances” appear in theform of electronic devices including, but not limited to, cellularphones, pagers, other hand-held devices (e.g., REX™, PalmPilot™ andWindows™ CE devices), personal computers (PCs) of all types and sizes,and Internet or intranet access devices (e.g., PCs or embedded computersrunning, for example, Java virtual machines or browsers or InternetProtocol (IP) handlers).

[0005] These devices, and the software applications running on thesedevices, do not communicate particularly well with one another and aretypically not designed with data synchronization in mind. Therefore, aproblem exists as to how one integrates information—such as calendaring,scheduling, and contact information—among disparate devices and softwareapplications. Consider, for instance, a user who has his or herappointments on a desktop PC at work, but also has a notebook computerat home, and a battery-powered, hand-held device for use in the field.What the user really wants is for the information (e.g., appointments)in each device to remain synchronized with corresponding information inall devices in a convenient and transparent manner. Still further, somedevices (e.g., PCs) are typically connected at least occasionally to aserver computer (e.g., an Internet server which stores information forthe user). The user would, of course, like the information on the servercomputer to participate in the synchronization so that the server alsoremains synchronized.

[0006] An early approach to maintaining consistency between data setswas to import or copy one data set on top of another. This simple“one-way” approach, which overwrites a target data set without anyattempt at reconciling any differences, is inadequate for all but thesimplest of applications. Not unexpectedly, more sophisticatedsynchronization techniques were developed. In particular, techniqueswere developed for synchronization of exactly two data sets byattempting to reproduce in each data set the changes found in the otherdata set since a previous synchronization. A detailed review ofdifferent synchronization techniques can be found in the Backgroundsection of commonly-owned application Ser. No. 08/923,612, filed Sep. 4,1997, and entitled System and Methods for Synchronizing InformationAmong Disparate Datasets, the disclosure of which is hereby incorporatedby reference in its entirety, including any appendices or attachmentsthereof, for all purposes.

[0007] Today, a variety of approaches exist for synchronizinginformation residing on multiple computing or information-storingdevices. Consider, for instance, the task of synchronizing respectivedata sets or “data stores” residing on a given pair of devices. Here,the particular synchronization process employed depends on thecapabilities of the individual devices. Consider, for instance, thefollowing two examples:

[0008] Example 1: A synchronization or “sync” engine communicating witha fairly primitive device may have to obtain a complete copy of the datastore from the device, do the comparison, and then re-write the entiredata store back to the device.

[0009] Example 2: The same sync engine, when communicating with ahigher-level device, may be able to send a request to the other (target)device for all changes to the data store that were made after the lastsync date. The target device will then transmit only those changes,reducing the amount of data that is transmitted and the time requiredfor synchronization.

[0010] Each example will be reviewed in turn.

[0011] Example 1 indicates a primitive synchronization process, where asynchronization engine must communicate with a primitive device (e.g.,one not including any native support for synchronization). In such acase, the synchronization engine must follow a resource-intensive (andtypically slow) process. First, the synchronization engine requests theentire data store from the device and then proceeds to determine whatdifferences exist in the data store by comparing it to apreviously-stored copy of the data store. After applying any necessarychanges (i.e., for creating a data store that is synchronized accordingto user-specified configuration), the synchronization engine must nowtransmit the entire copy back to the primitive device.

[0012] Example 2 indicates a higher-level synchronization process, inwhich the synchronization engine communicates with a device having atleast some degree of support for synchronization. Support might include,for example, the ability of the device to transmit to thesynchronization engine any new or modified records as of a certain date.Typically, the level of synchronization support is due in part to whatis stored in the data store, the type of program functionality (i.e.,software features) that is available, and the processing power that isavailable for the synchronization interface (to that device). Beyond thedisparate levels of synchronization illustrated by the precedingexamples, a variety of other possible levels exist, each one takingadvantage of the features of a particular device to get the mostefficient synchronization possible.

[0013] A problem exists with these present-day approaches, however. Inorder for two devices to synchronize together (i.e., participate in asynchronization session), they have to have some means ofcommunication—that is, a “synchronization protocol”. With existingsolutions, however, a “hard-wired” protocol (i.e., one supporting only aparticular device, such as a Palm Pilot device) is employed. As aresult, the protocol employed is specific to the needs and features of aparticular device, at the expense of not supporting other devices. Fromthe perspective of the software developer, one creates a device-specific“accessor” (i.e., driver capable of accessing data) for a particulartarget device, with the requirement that the developer knows theparticular synchronization capabilities of the target device beforehand.The problem with such an approach, however, is that the synchronizationdriver is tied to a specific device; it cannot be effectively re-usedfrom one device to another. As the target device itself typicallyundergoes revision, the device-specific driver soon becomes obsolete,since it does not support newer versions of the very same device forwhich it was specifically designed.

[0014] Recently, some attempts have been made to create generalizedsynchronization protocols. However, instead of handling a variety ofdifferent device synchronization-support levels, these protocols assumesome particular level of synchronization support, and only devicescapable of that level of support can be synchronized. Here, such aprotocol attempts to provide some degree of reuse by adopting a commondenominator for target devices using that protocol. This approach isalso problematic. Quite simply, if a device does not meet the commondenominator, it is completely shut out from use of the protocol, despitethe fact that the device may actually include some degree of built-insynchronization support (which could have been used to optimizesynchronization). In other words, the approach has no capability tosupport those devices which, although not adhering completely to thespecified protocol, have at least some intermediate level ofsynchronization support. Therefore, the approach is only an incrementalimprovement over the above-described single-device protocol.

[0015] What is needed are systems and methods that support a generalizedsynchronization protocol, yet do so in a manner which is adaptable tothe capabilities of a particular target device. In such a case, thetarget device is not required to have a particular degree ofsynchronization support in order to use the protocol. Instead, theprotocol allows the synchronization process to proceed in the mostefficient manner possible, given the level of synchronization supportprovided by the target device, whatever level that might be. The presentinvention fulfills this and other needs.

SUMMARY OF THE INVENTION

[0016] The present invention provides a methodology for “synchronizationprocess negotiation”—that is, negotiating between two or more devicesexactly what synchronization process (protocol) is to be employed toeffect synchronization of the devices. The methodology, which isadaptable to existing synchronization protocols, takes into account theactual synchronization capabilities or built-in support (if any) of eachdevice whose data is to be synchronized (e.g., by a synchronizationengine).

[0017] More particularly, the present invention may be implemented byadapting a given synchronization protocol (which itself may be one of avariety of types) to include a “negotiation phase” at the beginning ofthe synchronization, during which the devices involved will exchangeinformation about the capabilities of one or more devices. Once thisnegotiation phase has been completed, the synchronization can thenproceed in a manner that is most efficient for the features available.The present invention itself is actually independent of any particularliteral protocol, as it may be incorporated into a variety of differentsynchronization protocols, as well as different devices or differentcommunication (message transport) layers. Therefore, the focus of thepresent convention is, instead, on the adaptation of a synchronizationprotocol to incorporate a basic mechanism for negotiating thesynchronization process before synchronization begins, thereby governinghow synchronization proceeds.

[0018] In internal system operation, the present invention operates byintroducing the ability for a synchronization system's engine (syncengine) to query the client or target device about a particularattribute and to find out what the device's capabilities are in thatrespect. The individual attributes for a client are communicated assynchronization parameters, in attribute/value pair form. For example,the present invention introduces a “RECORD_FILTERING” parameter, whichmay be communicated from the client back to the synchronization engine,to allow the synchronization engine to determine what the client'scapabilities are with respect to filtering records from synchronization.The parameter may be set to one of the following values:

RECORD_FILTERING={NONE|HEADERS|SINCE_X}

[0019] NONE indicates that the client does not provide any recordfiltering functionality (i.e., similarly to Example 1 above); the clientcan only give the entire data store. HEADERS indicates that the clientcan provide record headers. Here, the client cannot pick out what haschanged, but it can provide a snapshot summary that is smaller than allof the data (from which the synchronization engine can then determinechanges). SINCE_X indicates that the client can provide records as of aparticular “Sync Anchor” value, where X indicates a time stamp or changecounter value (i.e., similarly to Example 2 above). Here, the client iscapable of giving records which have changed from a particular value(e.g., time stamp value for a particular date and time) given by thesynchronization engine.

[0020] In the event that the client can provide headers, the sync engineneeds to know what sort of information to expect in those headers inorder to perform synchronization. Possibilities include the following:

[0021] 1. Headers include a CRC (cyclic redundancy checking) value foreach record.

[0022] 2. Headers include a modification time (time stamp) for eachrecord.

[0023] 3. Headers include a change counter for each record.

[0024] These three options are reflected in a “CHANGE_TRACKING”parameter, which indicates what the device's capabilities are in termsof knowing what has changed. This parameter may be set to one of thefollowing values:

CHANGE_TRACKING={NONE|CRC|TIMESTAMP|CHANGE_COUNTER}

[0025] NONE indicates that the device or client has no ability todetermine if something has changed in its data store. CRC indicates aCRC value for each record; TIMESTAMP indicates a modification time foreach record; and CHANGE_COUNTER indicates a change count value for eachrecord.

[0026] Clients which cannot support a “SINCE_X” access method musteither transmit their entire data store or transmit headers. For suchclients, the sync engine will need to request the desired records fromthe device. For example, if the synchronization engine has determined,based on a comparison of CRC values, that a particular record haschanged, the synchronization engine needs a means to request that recordfrom the device. Different devices will provide different levels ofaccess and different types of access to their records, however.Therefore, a third parameter is required for specifying what type ofaccess is provided.

[0027] The types of record access that devices can support include thefollowing:

[0028] 1. The device can only transmit and receive the entire data storeas a block; it is not possible to request or submit individual records.

[0029] 2. The device provides “static index” access to the records(i.e., there are a fixed number of record storage “slots”, and the syncengine can request and submit records based on this slot number. Therecords may move to different slots in between synchronizations, sothere is no lasting fixed correlation between a slot number and arecord).

[0030] 3. The device provides “unique IDs” for each record, and the syncengine can request and submit individual records using these IDs. UniqueIDs are guaranteed to be unique within a particular data store, and theassociation between a record and its ID is never broken.

[0031] These three options are reflected in a “RECORD_ACCESS” parameter,which may take one of the following values:

RECORD_ACCESS={BLOCK|STATIC|UNIQUE}

[0032] BLOCK record access indicates that the device can only giveaccess to the entire set or “block” of records (i.e., the entire datastore); this is the most primitive type of record access. STATIC recordaccess indicates a static index mechanism. UNIQUE indicates that eachrecord within the data store is represented by a unique ID, within thescope or context of that particular data store (or, if desired, globallyunique). Here, the relationship between the unique identifier and therecord is fixed or permanent. This level of record access allows thesynchronization engine to get and put an individual record, based on theID.

[0033] A methodology of the present invention for synchronizing a firstdata set residing on a first device with a second data set residing on asecond device may be summarized as follows. At the outset, acommunication link is established between the two devices; this step maybe performed in a conventional manner, such as connecting the twodevices via a serial cable or via a local area network (LAN). Thisallows the second device to query the synchronization capabilities ofthe first device, by transmitting a request to the first device for thespecific synchronization capabilities of the first device. In responseto this request, the first device transmits back to the second deviceinformation indicating the specific synchronization capabilities of thefirst device. (If desired, the exchange of information aboutsynchronization capabilities may be extended to be bilateral or mutualin nature (or multilateral, in the case of three or more devices), suchthat the second device also communicates its synchronizationcapabilities back to the first device.) Now, based on the givensynchronization capabilities of the first device, a synchronizationprotocol may be selected for synchronizing the respective data sets ofthe two devices. Therefore, synchronization of the first and second datasets proceeds using the selected synchronization protocol, so that thesynchronization process is performed in a manner optimized for theavailable synchronization capabilities (e.g., of the first device).

BRIEF DESCRIPTION OF THE DRAWINGS

[0034]FIG. 1A is a block diagram of a computer system in which thepresent invention may be embodied.

[0035]FIG. 1B is a block diagram of a software system of the presentinvention for controlling operation of the computer system of FIG. 1A.

[0036] FIGS. 2A-E present flow charts illustrating the overall methodsteps employed for synchronization process negotiation.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

[0037] The following description will focus on the presently-preferredembodiment of the present invention, which is operative in anenvironment typically including a variety of computing orinformation-storing devices (e.g., desktop computers, server computers,and portable computing devices), that are occasionally or permanentlyconnected to one another where synchronization support is desired. Forpurposes of discussion, the following description will present examplesin which it will be assumed that there exists a “server” or“synchronization (“sync”) engine” which has one data store locally, anda “client’ or remote device which has a second data store to besynchronized. The present invention, however, is not limited to anyparticular environment or device. In particular, a client/serverdistinction is neither necessary to the invention nor even necessarilydesirable, but is used to provide a framework for discussion. The focusof the following description, therefore, is not focused on a particularsynchronization/hardware configuration (as the present invention may beadvantageously applied to a variety of disparate configurations).Instead, the following description will focus on the application ofsynchronization negotiation or dialog among two or more devices, whichmay be configured in a variety of hardware configurations (e.g.,according to the particular needs of the user). Therefore, the followingdescription is for the purposes of illustration and not limitation.

[0038] Brief Overview of Synchronization

[0039] A. Introduction

[0040] Many software applications, such as personal productivityapplications like Starfish Sidekick® and Lotus® Organizer, have sets ofdata or “data sets” (e.g., address books and calendars). Consider, forinstance, a user scenario where an account executive needs to coordinatecontacts and events with other employees of the XYZ corporation. Whentraveling, the executive carries a laptop PC with Starfish Sidekick®installed. At home, she and her husband use Lotus® Organizer to plantheir family's activities. When on family outings, the account executivecarries her PalmPilot™ hand-held organizer. As the foregoingillustrates, a user often needs a means for synchronizing selectedinformation from the data sets his or her applications rely upon. Theaccount executive would not want to schedule a business meeting at thesame time as a family event, for example.

[0041] Conventionally, the process of synchronizing or reconciling datasets has been a binary process—that is, two logical data sets aresynchronized at a time. Any arbitrary synchronization topology will besupported. Here, the system guarantees synchronization stability and theavoidance of undesirable side effects (cascading updates, recordduplication, or the like). Data sets do not need to be directlyconnected but, instead, can be connected via a “store-and-forward”transport, such as electronic mail.

[0042] B. Synchronization design

[0043] 1. Synchronization Type

[0044] Data set synchronization may, for convenience of description, bedivided into two types: content-oriented and record-oriented.Content-oriented synchronization correlates data set records based onthe values of user-modifiable fields. Value correlation requiressemantic (or at least advanced syntactic) processing that the humanbrain is very good at and computers are not. For example, a record inone data set with a name field valued “Johann S. Bach” and a record in asecond data set with a name field valued “J. S. Bach” could possiblyrefer to the same real-world person. A human being might arrive at thisconclusion by correlating associated data (addresses) or drawing uponexternal information (e.g., Bach is an unusual name in the U.S.).Creating program logic or code with the ability to make these types ofdecisions is computationally very expensive.

[0045] Record-oriented synchronization correlates data set records byassuming that each record can be uniquely identified throughout itslifetime. This unique identifier is usually implemented as anon-modifiable, hidden field containing a “Record ID”. Record-orientedsynchronization algorithms usually require maintaining a mapping fromone set of record IDs to another. In a preferred embodiment, the systememploys record-oriented synchronization.

[0046] Record-oriented synchronization is conceptually simple and may besummarized as follows. In the rules below, A and B refer to two datasets which have a synchronization relationship. The rules are assumed tobe symmetrical.

[0047] 1. A and B must track similar types of data (e.g., if A is anaddress book, then B must be an address book).

[0048] 2. A record created in A, will create a record in B.

[0049] 3. A record modified in A, will modify the corresponding recordin B.

[0050] 4. If record A1 has been modified in A and the correspondingrecord B1 has been modified in B, the record with the latest time stamp(also, “timestamp”) takes precedence.

[0051] The rules presented above reduce the occurrence of undesirableside effects with a network of synchronized data sets.

[0052] 2. Time Stamps

[0053] The actual synchronization logic in synchronization systems oftenneeds to make processing decisions based on comparing the time at whichpast events occurred. For example, it is necessary to know if a recordwas modified before or after the last synchronization transaction. Thisrequires recording the time of various events. A “time stamp” value maybe employed for this purpose. Typically, data sets involved insynchronization support time stamps, or can be supplied with suitabletime stamps, in a conventional manner. In conjunction with the usage oftime stamps to compare the relative timing of record creation ormodification, the clocks on the respective devices may themselves besynchronized.

[0054] 3. Record Transformations

[0055] During synchronization, a synchronization system will typicallytransform records from one application-usage-schema set to anotherapplication-usage-schema set, such as transforming from a StarfishSidekick® card file for business contacts to a corresponding PalmPilot™data set. Typically, there is a one-to-one relationship between recordsin these two data sets, that is, between the source and target datasets. If this is not the case, however, the component of the system thatinteracts with a non-conforming data set may include logic to handlethis non-conformance.

[0056] The record transformations themselves are a combination of fieldmappings and conversions from a source record to a target record.Exemplary types of field mappings include, for instance, the following:

[0057] 1. Null Source field has no equivalent field in the target dataset and is ignored during synchronization.

[0058] 2. One-to-One Map exactly one field in the target data set to onefield in the source data set.

[0059] 3. One-to-Many Map one field in the target data set to manyfields in the source data set, such as parse a single address line tofields for number, direction, street, suite/apartment, or the like.

[0060] 4. Many-to-One Map several fields in the target data set to onefield in the source data set, such as reverse the address line mappingabove.

[0061] Similarly, exemplary field conversions may be defined as follows:

[0062] 1. Size Source field may be larger or smaller in size than thetarget field.

[0063] 2. Type Data types may be different, such as float/integer,character vs. numeric dates, or the like.

[0064] 3. Discrete Values A field's values may be limited to a knownset. These sets may be different from target to source and may be userdefined.

[0065] It is often the case that there are significant differences inthe number, size, type, and usage of fields between two data sets in asynchronization relationship. The specification of transformations istypically user-configurable, with the underlying system providingdefaults.

[0066] With an understanding of the basic process of synchronizinginformation or computing devices, the reader may now better appreciatethe teachings of the present invention for providing improvedsynchronization methodology for synchronizing an arbitrary number ofdevices (i.e., synchronization clients), as described in further detailbelow. As will be noted in further detail below, however, themethodology of the present invention for negotiating a particularsynchronization process is largely independent of any givensynchronization process or synchronization engine. Instead, themethodology of the present invention operates to allow devicesparticipating in a synchronization process to select a specific type ofprocess (or synchronization path of execution for a givensynchronization engine), based on the capabilities of one or more of theparticipating devices.

[0067] This allows the synchronization process to be optimized based onthe built-in synchronization support of the participating devices.

[0068] System Hardware and Software

[0069] The present invention may be embodied on an informationprocessing system such as the system 100 of FIG. 1A, which comprises acentral processor 101, a main memory 102, an input/output (I/O)controller 103, a keyboard 104, a pointing device 105 (e.g., mouse, pendevice, or the like), a screen or display device 106, a mass storage 107(e.g., hard disk, removable floppy disk, optical disk, magneto-opticaldisk, flash memory, or the like), one or more optional output device(s)108, and an interface 109. Although not shown separately, a real-timesystem clock is included with the system 100, in a conventional manner.The various components of the system 100 communicate through a systembus 110 or similar architecture. In addition, the system 100 maycommunicate with other devices through the interface or communicationport 109, which may be an RS-232 serial port or the like.

[0070] Devices which will be commonly connected to the interface 109include a network 151 (e.g., LANs or the Internet), a laptop 152, ahandheld organizer 154 (e.g., the REXTM organizer, available fromFranklin Electronic Publishers of Burlington, N.J.), a modem 153, or thelike.

[0071] In operation, program logic (implementing the methodologydescribed below) is loaded from the storage device or mass storage 107into the main memory 102, for execution by the processor 101. Duringoperation of the program (logic), the user enters commands through thekeyboard 104 and/or pointing device 105, which is typically a mouse, atrack ball, or the like. The computer system displays text and/orgraphic images and other data on the display device 106, such as acathode-ray tube or an LCD display. A hard copy of the displayedinformation, or other information within the system 100, may be obtainedfrom the output device 108 (e.g., a printer). In a preferred embodiment,the computer system 100 includes an IBM PC-compatible personal computer(available from a variety of vendors, including IBM of Armonk, N.Y.)running Windows 9x or Windows NT (available from Microsoft Corporationof Redmond, Wash.). In a specific embodiment, the system 100 is anInternet, intranet, or other type of network server and receives inputfrom, and sends output to, a remote user via the interface 109 accordingto standard techniques and protocols.

[0072] Illustrated in FIG. 1B, a computer software system 120 isprovided for directing the operation of the computer system 100.Software system 120, which is stored in system memory 102 and on storage107 (e.g., disk memory), includes a kernel or operating system (OS) 140and a windows shell 150. One or more application programs 145, such asclient application software or “programs” may be “loaded” (i.e.,transferred from storage 107 into memory 102) for execution by thesystem 100.

[0073] System 120 includes a user interface (UI) 160, preferably aGraphical User Interface (GUI), for receiving user commands and data andfor producing output to the user. These inputs, in turn, may be actedupon by the system 100 in accordance with instructions from operatingsystem module 140, windows module 150, and/or client applicationmodule(s) 145. The UI 160 also serves to display the user prompts andresults of operation from the OS 140, windows 150, and application(s)145, whereupon the user may supply additional inputs or terminate thesession. In the preferred embodiment, OS 140 and windows 150 togethercomprise Microsoft Windows software (e.g., Windows 9x or Windows NT).Although shown conceptually as a separate module, the UI is typicallyprovided by interaction of the application modules with the windowsshell and the OS 140.

[0074] Although the methodology of the present invention may be embodiedon a single device for synchronizing or reconciling multiple data setspresent on that device, the present invention will instead typically beembodied in an environment including two or more computing orinformation-storing devices, which are occasionally or continuallyconnected. For purposes of the discussion which follows, therefore, itis convenient to consider an embodiment of the present intention in aclient/server-like system having a client (e.g., hand-held or portable“organizer” device 154, laptop computer 152, or the like) incommunication with a synchronization engine residing on a “host” or“server” computer (e.g., computer system 100). The synchronizationengine itself is constructed to effect reconciliation or synchronizationamong two or more data sets, according to user-specified conditions orcriteria. For a description of the details construction and operation ofa synchronization engine, see e.g., commonly-owned application Ser. No.09/136,212, filed Aug. 18, 1998, the disclosure of which has previouslybeen incorporated by reference.

[0075] The present invention is not limited to any particularsynchronization engine or hardware configuration but, instead, may beadvantageously employed in any environment requiring and capable ofsupporting synchronization of two or more data stores. For example, thelaptop computer 152 may serve as the “server” with both the computersystem 100 and the organizer device 154 serving as “clients.” Hence, forpurposes of the present invention, which device functions as a “client”(or multiple devices functioning as “clients”) and which devicefunctions as a “server,” is largely an arbitrary choice. And ininstances where the present invention is employed to supportpeer-to-peer configurations, the use of “client” and “server”distinctions is in fact not even applicable. Therefore, although thedistinction of a particular device being a “client” and another devicebeing a “server” is useful as a framework for presenting exemplarysynchronization scenarios for application of the present invention, thepresent invention itself actually requires no such distinction.

[0076] Additionally, the means for communication may be one of a varietyof communication means, including serial link (e.g., RS 232 wired link),parallel link, infrared link, wireless (cellular) link, or the like. Thepresent invention is independent of communication means, so long assynchronization messages can eventually be transmitted and received,whether in a synchronous or asynchronous manner. Instead, what isrequired is an interface to the underlying synchronization protocol(whatever that protocol may be), so that there exists some means ofinitiating a synchronization session which is adapted to include anegotiation phase of the present invention, as described below.Typically, the interface would be implemented in program code existingat the target device and complementary program code existing at thesynchronization engine, so that the two may exchange messages orcommands (including parameter information) in the format specified bythe particular synchronization protocol. The synchronization protocolshould, however, at least allow the exchange of attribute information,so that synchronization attributes of the target device may becommunicated to the synchronization engine.

[0077] Synchronization Process Negotiation

[0078] A. Overview

[0079] The present invention introduces into a given synchronizationprotocol (which itself may be one of a variety of types) a “negotiationphase” at the beginning of the synchronization, during which the devicesinvolved will exchange information about the capabilities of one or moredevices. Typically, the capabilities of the client device are thelimiting factor for synchronization, so that the negotiation phase mayproceed by only including enumeration of the client's capabilities. Oncethis negotiation phase has been completed, the synchronization can thenproceed in a manner that is most efficient for the features that areavailable. The present invention itself is actually independent of anyparticular literal protocol, as it may be incorporated into a variety ofdifferent synchronization protocols, as well as different devices ordifferent communication (message transport) layers. Therefore, the focusof the present convention is, instead, on the adaptation of asynchronization protocol to incorporate a basic mechanism fornegotiating the synchronization process before synchronization begins,thereby governing how synchronization proceeds.

[0080] B. Synchronization Processes

[0081] From the perspective of a synchronization engine, a givensynchronization process may be divided into the following basic steps(using the above-described client/server framework for discussion):

[0082] 1. Figure out what records have changed on the client (i.e.,target device).

[0083] 2. Reconcile those changes with the local data store.

[0084] 3. Update the client data store appropriately.

[0085] How these three steps are actually performed varies significantlyfrom one client to another, depending upon the capabilities of theunderlying device. For instance, as previously illustrated in Example 1and Example 2 above, the task of figuring out what records have changedon the client varies considerably, depending on capabilities of theclient. Therefore, of particular interest herein is the process to beused for these steps that is negotiated in the “negotiation phase”before synchronization begins.

[0086] With regard to step 1 above, three different ways exist that async engine can figure out what has changed on the client:

[0087] 1. Download the entire data store and compare to a previouslystored copy (slowest).

[0088] 2. Download a set of record “headers” (e.g., containing timestamp or signature/checksum information) which can be compared to aprevious copy to determine what has changed. This approach is fasterthan #1, since less information is transmitted.

[0089] 3. Ask the device to transmit all the records which have changedsince a particular “Sync Anchor” value (fastest). Here, Sync Anchorrefers to a value, such as a time stamp or a change counter (e.g., valueincremented each time a record is changed), that allows one to determinewhether a record has changed since a particular point in time, usuallysince last synchronization. This is a value which is associated with aparticular record and is changed whenever the record is changed. Thesync engine can then compare this value to a previously stored value todetect that changes have been made.

[0090] The present invention introduces the ability for thesynchronization engine to query the client or target device about aparticular attribute, to find out what the device's capabilities are inthat respect. (As previously described, the approach is adaptable to avariety of different synchronization engines, including for example thesynchronization engine described by application Ser. No. 09/136,212).Given the above ways in which a synchronization engine can determinewhat has changed on a client, the present invention introduces a“RECORD_FILTERING” parameter, to allow the synchronization engine todetermine what the client's capabilities are with respect to these threeprocesses (i.e., with respect to filtering records fromsynchronization). The parameter may be set to one of the followingvalues:

RECORD_FILTERING={NONE|HEADERS|SINCE_X}

[0091] NONE indicates that the client does not provide any recordfiltering functionality (i.e., process #1 above); the client can onlygive the entire data store. HEADERS indicates that the client canprovide record headers (i.e., process #2 above). Here, the client cannotpick out what has changed, but it can provide a snapshot summary that issmaller than all of the data (from which the synchronization engine canthen determine changes). SINCE_X indicates that the client can providerecords as of a particular “Sync Anchor” value, where X indicates a timestamp or change counter value. Here, the client is capable of providingrecords which have changed from a particular value (e.g., time stampvalue for a particular date and time) given by the synchronizationengine.

[0092] In the event that the client can provide headers, the sync engineneeds to know what sort of information to expect in those headers inorder to perform synchronization. Possibilities include the following:

[0093] 1. Headers include a CRC (cyclic redundancy checking) value foreach record.

[0094] 2. Headers include a modification time (time stamp) for eachrecord.

[0095] 3. Headers include a change counter for each record.

[0096] These three options are reflected in a “CHANGE_TRACKING”parameter, which indicates what the device's capabilities are in termsof knowing what has changed. This parameter may be set to one of thefollowing values:

CHANGE_TRACKING={NONE|CRC|TIMESTAMP|CHANGE_COUNTER}

[0097] NONE indicates that the device or client has no ability todetermine if something has changed in its data store. CRC indicates aCRC value for each record; TIMESTAMP indicates a modification time foreach record; and CHANGE_COUNTER indicates a change count value for eachrecord.

[0098] Clients which cannot support a “SINCE_X” access method musteither transmit their entire data store or transmit headers. For suchclients, the sync engine will need to request the desired records fromthe device. For example, if the synchronization engine has determined,based on comparison of CRC values that a particular record has changed,the synchronization engine needs a means in order to request that recordfrom the device. Different devices will provide different levels ofaccess and different types of access to their records, however.Therefore, a third parameter is required for specifying what type ofaccess is provided.

[0099] The types of record access that devices can support include thefollowing:

[0100] 1. The device can only transmit and receive the entire data storeas a block; it is not possible to request or submit individual records.

[0101] 2. The device provides “static index” access to the records(i.e., there are a fixed number of record storage “slots”, and the syncengine can request and submit records based on this slot number. Therecords may move to different slots in between synchronizations, sothere is no lasting fixed correlation between a slot number and arecord).

[0102] 3. The device provides “unique IDs” for each record, and the syncengine can request and submit individual records using these IDs. UniqueIDs are guaranteed to be unique within a particular data store, and theassociation between a record and its ID is never broken.

[0103] These three options are reflected in a “RECORD_ACCESS” parameter,which may take one of the following values:

RECORD_ACCESS={BLOCK|STATIC|UNIQUE}

[0104] BLOCK record access indicates that the device can only giveaccess to the entire set or “block” of records (i.e., the entire datastore); this is the most primitive type of record access. STATIC recordaccess indicates a static index mechanism. For example, a MotorolaStarTac® phone provides 99 slots for storing phone numbers. Asynchronization engine can request, for instance, the contents of slot#5. There is, however, no association between the slot number and thevalue stored (i.e., record contents), and in fact the phone can shufflethe records around at its discretion. UNIQUE indicates that each recordwithin the data store is represented by a unique ID, within the scope orcontext of that particular data store. Here, the relationship betweenthe unique identifier and the record is fixed or permanent. This levelof record access allows the synchronization engine to get and put anindividual record, based on the ID.

[0105] B. Example Utilizing Parameter Information

[0106] Based on the just-described three synchronization-negotiationparameters of the present invention, the synchronization engine can usethe parameters to control the synchronization process and to pick asynchronization process that is optimized for a particular targetdevice. When the sync engine is able to query the device for itssynchronization capabilities using these three basic parameters,therefore, it becomes possible for the sync engine to proceed with amethod of synchronization that is appropriate to the capabilities of thedevice. This is perhaps best illustrated by way of example, using thefollowing for synchronization processes.

[0107] Consider the following four synchronization processes, with theircorresponding parameter values:

EXAMPLE #1

[0108] Synchronization Attribute Parameters:

[0109] RECORD_FILTERING=NONE

[0110] CHANGE_TRACKING=NONE

[0111] RECORD_ACCESS=BLOCK

[0112] Optimal Synchronization Process Available:

[0113] (a) Obtain complete data store;

[0114] (b) Perform sync locally; and

[0115] (c) Replace entire data store.

EXAMPLE #2

[0116] Synchronization Attribute Parameters:

[0117] RECORD_FILTERING=NONE

[0118] CHANGE_TRACKING=NONE

[0119] RECORD_ACCESS=STATIC|UNIQUE

[0120] Optimal Synchronization Process Available:

[0121] (a) Obtain complete data store;

[0122] (b) Perform sync locally; and

[0123] (c) Replace only affected records.

EXAMPLE #3

[0124] Synchronization Attribute Parameters:

[0125] RECORD_FILTERING=HEADERS

[0126] CHANGE_TRACKING=CRC|TIMESTAMP|CHANGE_COUNTER

[0127] RECORD_ACCESS=UNIQUE

[0128] Optimal Synchronization Process Available:

[0129] (a) Obtain a summary of all records which includes per-recordchange-tracking information;

[0130] (b) Fetch only the changed records;

[0131] (c) Perform sync; and

[0132] (d) Replace only affected records.

EXAMPLE #4

[0133] Synchronization Attribute Parameters:

[0134] RECORD_FILTERING=SINCE_X

[0135] CHANGE_TRACKING=TIMESTAMP|CHANGE_COUNTER

[0136] RECORD_ACCESS=UNIQUE

[0137] Optimal Synchronization Process Available:

[0138] (a) Request only the changed records from the device;

[0139] (b) Perform sync; and

[0140] (c) Replace only the affected records.

[0141] The following illustrates an exemplary communication session forsuch a case. TABLE 1 EXEMPLARY COMMUNICATION SESSION Client ServerNotes: Login LoginResponse Request Sync Attributes Return SyncAttributes RequestChangesSinceX UpdateRecord UpdateRecord LastRecordSentAckLastRecordSent Perform synchronization at server DeleteRecordInsertRecord UpdateRecord LastRecordSent AckLastRecordSent UpdateMap(optional details) LastMapSent AckLastMapSent Logout

[0142] This synchronization session demonstrates exchange (e.g.,synchronization protocol-based dialog) in which the target device iscapable of knowing which records to send to the server, based on thelast sync time communicated during login. Here, the server performssynchronization (including, conflict resolution) after receiving allclient changes. Alternatively, the server may be configured to performsynchronization or at least some degree of conflict resolution uponreceipt of each client record (i.e., process does not wait until receiptof all client records before commencing).

[0143] C. Methodology summarized

[0144] FIGS. 2A-E present flow charts illustrating the overall methodsteps employed for synchronization process negotiation. In step 201, therespective devices establish a communication link (i.e., establishcommunication link between target device(s), client(s), andsynchronization engine). In step 202, the devices exchangeacknowledgments for initiating synchronization protocol. In step 203,the devices begin synchronization negotiation by eliciting thesynchronization capabilities of the target device(s). This occurs, forinstance, by transmitting a request from the synchronization engine tothe client for synchronization parameters or attributes of the client.As indicated by step 204, in response to this request, the clienttransmits synchronization parameters indicating the client'scapabilities. In the currently-preferred embodiment, such parameters orattributes include: (1) whether records are filtered (RECORD_FILTERparameter), (2) what type of change tracking (e.g., time stamp or changevalue) is provided at the client (CHANGE_TRACKING parameter), and (3)what level of record access is afforded by the client (RECORD_ACCESSparameter). Based on the transmitted parameter values, thesynchronization engine will select an optimal synchronization process orstrategy.

[0145] Processing at this point depends on the actual values set in theparameters. In other words, how the synchronization process proceedsfrom this point on depends, at least in part, on the synchronizationcapabilities (if any) of the client: a synchronization protocol isselected that allows optimization of the synchronization process, basedon client capabilities. The processing logic applied by the method atthis point is summarized by step 205. In the event that record filteringis set to “none”, change tracking is set to “none”, and record access isset to “block”, the method proceeds to steps to 211-213 (case instanceor condition A). In such a case, the synchronization engine obtains thecomplete data store (step 211), performs synchronization locally (step212), and then replaces the entire data store (step 213), as shown inFIG. 2B. In the event that record filtering is set to “none”, changetracking is set to “none”, and record access is set to “static” or“unique”, the method proceeds to steps to 221-223 (case condition B).Here, the synchronization engine obtains the complete data store (step221), performs synchronization locally (step 222), but then onlyreplaces the affected records (step 223), as shown in FIG. 2C.

[0146] Continuing with the other case conditions, in the event thatrecord filtering is set to “headers”, change tracking is set to “CRC”,or “timestamp” or “change counter”, and record access is set to“unique”, the method proceeds to steps to 231-234 (case condition C). Insuch a case, the synchronization engine obtains a summary of all recordswhich includes per record change-tracking information (step 231),fetches only the changed records (step 232), performs synchronizationlocally (step 233), and then replaces only the affected records (step234), as shown in FIG. 2D. In the event that record filtering is set to“since X change” tracking, change tracking is set to “time stamp” or“change counter”, and record access is set to “static” or “unique”, themethod proceeds to steps to 241-243 (case condition D). Here, thesynchronization engine requests only the changed records from the targetdevice (step 241), performs synchronization locally (step 242), and thenonly replaces the affected records (step 243), as shown in FIG. 2E.After conclusion of the proper case condition invocation, the method isdone.

[0147] The above demonstrates that, based on synchronization parametercombinations, the synchronization engine proceeds with synchronizationin a manner selected to optimize the process, based on the capabilitiesof the particular target device participating in synchronization. Theability of the client to facilitate the process is utilized based on therecognition by the synchronization engine that the client is able toassist in the process. Here, in contrast to hard-wired approaches inprior art systems, the synchronization engine adapts to the capabilitiesof each individual client, even though each client itself may have adegree of support for synchronization that is quite different than thatof other clients. In effect, both the client and the synchronizationengine “negotiate” as to the best synchronization process to use.Synchronization then proceeds based on the negotiated or agreed-uponsynchronization protocol (which itself can be any one of a number ofsynchronization protocols).

[0148] D. Conclusion

[0149] By providing a mechanism to access basic synchronizationparameters, the present invention allows a sync engine to effectsynchronization among a variety of different devices in a manner that isoptimal for the capabilities of each particular device. In this fashion,the amount of traffic (information) over the communication link may beminimized. This is particularly important in configurations having slowcommunication links (e.g., serial cable link) and/or large amounts ofdata. Additionally, the amount of work which the synchronization enginemust do is minimized. All told, the present invention solves thepreviously-described problem that exists with these present-dayapproaches employing a “hard-wired” protocol approach: a synchronizationprotocol may be negotiated between or among an arbitrary set of devices,such that an optimal synchronization protocol is selected for thosedevices.

[0150] While the invention is described in some detail with specificreference to a single preferred embodiment and certain alternatives,there is no intent to limit the invention to that particular embodimentor those specific alternatives. Thus, the true scope of the presentinvention is not limited to any one of the foregoing exemplaryembodiments but is instead defined by the appended claims.

What is claimed is:
 1. In a data processing environment, a method forsynchronizing a first data set residing on a first device with a seconddata set residing on a second device, the method comprising:establishing a communication link between said first and second devices;transmitting from the second device to the first device a request forsynchronization capabilities of the first device; in response to saidrequest, transmitting from the first device to the second deviceinformation indicating said synchronization capabilities of the firstdevice; based on said synchronization capabilities of the first device,selecting a synchronization protocol for synchronizing said first andsecond data sets; and performing synchronization of said first andsecond data sets using said selected synchronization protocol, whereinsaid synchronization is performed in a manner optimized for thesynchronization capabilities of the first device.
 2. The method of claim1 , wherein said communication link comprises a wireless link.
 3. Themethod of claim 1 , wherein said communication link comprises a wiredlink.
 4. The method of claim 1 , wherein said first and second devicesare only occasionally connected via said communication link.
 5. Themethod of claim 1 , wherein said first and second devices arepersistently connected via said communication link.
 6. The method ofclaim 1 , wherein said request for synchronization capabilities of thefirst device comprises a communication message requestingsynchronization parameters from the first device.
 7. The method of claim6 , wherein said synchronization parameters comprise attribute/valuepairs indicating synchronization capabilities of the first device. 8.The method of claim 6 , wherein said synchronization parameters includea record filtering parameter indicating what capability the first devicehas for filtering records from synchronization.
 9. The method of claim 8, wherein said record filtering parameter can express a value of “none”to indicate that the first device has no record filtering capability.10. The method of claim 8 , wherein said record filtering parameter canexpress a value indicating that the first device has the capability ofproviding record headers for records of the first data set.
 11. Themethod of claim 8 , wherein said record filtering parameter can expressa value indicating that the first device has the capability of providingonly those records of the first data set which meet a particularcondition.
 12. The method of claim 11 , wherein said particularcondition comprises a synchronization anchor value against which recordsare tested.
 13. The method of claim 12 , wherein said synchronizationanchor value comprises a time stamp value.
 14. The method of claim 12 ,wherein said synchronization anchor value comprises a change countervalue.
 15. The method of claim 14 , wherein said change counter valuecomprises a value incremented each time a particular record is changed,thereby allowing a device to determine whether a change has occurred tothe particular record.
 16. The method of claim 6 , wherein saidsynchronization parameters include a change tracking parameterindicating what type of information the first device provides whentransmitting record headers.
 17. The method of claim 16 , wherein saidchange tracking parameter comprises a selected one of a cyclicredundancy checking (CRC) value, a time stamp value, and a changecounter value.
 18. The method of claim 6 , wherein said synchronizationparameters include a record access parameter indicating what level ofaccess the first device provides to other devices.
 19. The method ofclaim 18 , wherein said record access parameter comprises a valueindicating that the first device can only give access to the entirefirst data set.
 20. The method of claim 19 , wherein said valueindicating that the first device can only give access to the entirefirst data set comprises a “block” value.
 21. The method of claim 18 ,wherein said record access parameter comprises a value indicating thatthe first device can give access to individual records of the first dataset through a static index mechanism.
 22. The method of claim 21 ,wherein said value indicating that the first device can give access toindividual records of the first data set through a static indexmechanism comprises a “static” value.
 23. The method of claim 18 ,wherein said record access parameter comprises a value indicating thatthe first device can give access to individual records of the first dataset using a unique identifier for each record.
 24. The method of claim23 , wherein said value indicating that the first device can give accessto the individual records of the first data using a unique identifierfor each record comprises a “unique” value.
 25. The method of claim 23 ,wherein said value indicating that the first device can give access tothe individual records of the first data using a unique identifierindicates that the first device allows other devices to get and put anindividual record, based on an ID that is unique to that record . 26.The method of claim 23 , each unique identifier for records of the firstdevice is a selected one of an identifier that is unique within thescope of the first device and an identifier that is globally unique. 27.A method for synchronizing a first device having a first data set with asecond device having a second data set, the method comprising:selectively connecting the first device to a second device, forestablishing communication between the two devices; negotiating asynchronization process for synchronizing said first and second datasets by performing substeps of: sending a request from the second deviceto the first device for synchronization capabilities of the firstdevice; in response to said request, transmitting from the first deviceto the second device synchronization parameters conveying thesynchronization capabilities of the first device; and based on saidsynchronization parameters received from the first device, selecting asynchronization process for synchronizing said first and second datasets; and performing synchronization of said first and second data setsusing said selected synchronization process.
 28. The method of claim 27, wherein synchronization parameters indicate that the first deviceprovides no record filtering, provides no change tracking, and providesblock record access, and wherein said synchronization step is performedby: (a) transmitting from the first device to the second device anentire copy of the first data set; (b) performing synchronizationlocally at the second device, using said copy of the first data set; and(c) once said copy of the first data set has been synchronized,replacing the first data set of the first device with the copy of thefirst data set which has been synchronized at the second device.
 29. Themethod of claim 27 , wherein synchronization parameters indicate thatthe first device provides no record filtering, provides no changetracking, and provides record access using either a static index or aunique record identifier, and wherein said synchronization step isperformed by: (a) transmitting from the first device to the seconddevice an entire copy of the first data set; (b) performingsynchronization locally at the second device, using said copy of thefirst data set; and (c) once said copy of the first data set has beensynchronized, replacing only those records of the first data set of thefirst device that are affected by the synchronization.
 30. The method ofclaim 27 , wherein said synchronization parameters indicate that thefirst device provides record filtering using record headers, provideschange tracking, and provides record access using a unique recordidentifier, and wherein said synchronization step is performed by: (a)transmitting from the first device to the second device a summary of thefirst data set, which includes per record change-tracking information;(b) based on said change-tracking information, transmitting from thefirst device to the second device a copy of only those records of thefirst data set which have changed; (c) performing synchronizationlocally at the second device, using said copy of only those records ofthe first data set which have changed; and (d) once said copy of thefirst data set has been synchronized, replacing each record of the firstdata set of the first device that is affected by the synchronization,using the unique record identifier for each record.
 31. Asynchronization system comprising: a communication link between a firstdata set from a first device with a second data set from a seconddevice; a synchronization engine for enumerating particularsynchronization capabilities of devices and for performingsynchronization between data sets; a synchronization interface capableof responding to said synchronization engine, for transmitting from thefirst device information indicating the particular synchronizationcapabilities of the first device; and whereupon said synchronizationengine selects a particular synchronization process for synchronizingsaid first and second data sets, based on the particular synchronizationcapabilities of the first device, and thereafter performssynchronization of said first and second data sets using said selectedsynchronization process.
 32. The system of claim 31 , wherein saidcommunication link is a selected one of a wireless communication linkand a wired communication link.
 33. The system of claim 32 , whereinsaid wireless communication link comprises a cellular phone link. 34.The system of claim 32 , wherein said wired communication link comprisesa serial RS232 communication link.
 35. The system of claim 31 , whereinsaid communication link comprises a selected one of a synchronouscommunication link and an asynchronous communication link.
 36. Thesystem of claim 31 , wherein said synchronization interface resides, atleast in part, at said first device.
 37. The system of claim 31 ,wherein said synchronization interface supports communication ofsynchronization commands and parameters between said first and seconddevices.
 38. The system of claim 31 , wherein said informationindicating the particular synchronization capabilities of the firstdevice comprises synchronization parameters.
 39. The system of claim 38, wherein said synchronization parameters comprise attribute/value pairsindicating synchronization capabilities of the first device.
 40. Thesystem of claim 38 , wherein said synchronization parameters include arecord filtering parameter indicating what capability the first devicehas for filtering records from synchronization.
 41. The system of claim38 , wherein said synchronization parameters include a change trackingparameter indicating what type of information the first device canprovide by transmitting only record headers.
 42. The system of claim 38, wherein said synchronization parameters include a record accessparameter indicating what level of access the first device provides toother devices.